Vision Document

Author: <author>

Version <1.0>

Date created: November 3, 2014

Date revised: XXX 0, 0000

[Note: The following template will be used to document Discovery phase activities. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]

[To customize automatic fields (which display a gray background when selected), select File>Properties and replace the Title and Subject fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields. Use the “REPLACE ALL” function within Word to change <Project ID: Project Name> to the actual project ID# and name. ]

Table of Contents

1.	Project Summary	1

1.1	Summary	1

1.2	Document Conventions	1

1.3	Business Opportunity/Problem Statement	1

2.	Stakeholder Needs and Product Features	1

3.	Project Boundaries	1

3.1	Scope	1

3.1.1	In-Scope	1

3.1.2	Project Scope Diagram	1

3.1.3	Out-of-Scope	1

3.2	Assumptions	1

3.3	Dependencies	1

3.4	Constraints	1

4.	Product Positioning	1

4.1	Vision Statement	1

4.2	Business Landscape	1

4.3	Vendor Landscape	1

5.	Common Terminology	1

6.	Stakeholder Summary	1

6.1	Market Demographics	1

6.2	Business Organization Charts	1

6.3	Stakeholders and Key Persons	1

7.	Documentation References	1

Vision Document

Project Summary

Summary

[Provide a summary of the project. This information is produced by the business or the BA helping the business describe in business terms of project scope and what will be accomplished when the project is completed.]

Document Conventions

[Provide any document conventions that are used throughout this document. An effective method might be a two column table, one for Convention and one for Description. An example of this might be color coding around different releases.]

Business Opportunity/Problem Statement

[Briefly describe the business opportunity or problem being met by this project. If a Business Opportunity/Problem statement has not been defined, the Business Analyst must elicit the information from the business stakeholders. When describing a Business Opportunity, avoid making statements that are technology oriented in favor of ones that are user oriented. For example, "create a cushioning system" is technology oriented, where as "improve comfort while kneeling" is user oriented.

When describing a Business Problem, the following formats are recommended as a way to elicit the information. PLEASE CHOOSE ONE OR THE OTHER AS BEST SUITS YOUR NEEDS. Table Type 1 should be used if the affected stakeholders have the same impact and successful solutions as each other. Table Type 2 should be used if the affected stakeholders are impacted differently and if their idea of a successful solution is different than other stakeholders. This statement must include measurable characteristics and any financial aspects to support the business goals. (Note: either complete a table with project-specific information or delete the table from the Vision document and construct the statement as needed.)]

The problem of	(describe the problem)
Affects a	(the stakeholders affected by the problem)
The impact of which is	(what is the impact of the problem)
A successful solution would	(list some key business benefits of a successful solution)

Table Type 1 – Business Problem Statement

The problem of	(describe the problem)
Affects	The impact of which is	A successful solution would
(the stakeholders affected by the problem)	(what is the impact of the problem for each of the stakeholders affected)	(list some key business benefits of a successful solution for each of the stakeholders affected)

Table Type 2 – Business Problem Statement

Stakeholder Needs and Product Features

[In this section, document the high-level needs and features requested by the stakeholders. A stakeholder need is derived from the voice of the customer sessions held with the stakeholders, and specifically captures the high-level needs from the business perspective. Needs may describe the financial, marketplace or other business benefits that either customers or the organization can gain from the product, and are the highest-level requirements of the system. Product features are the high-level capabilities of the system that are necessary to deliver benefits to the users. A feature is a summary of a set of behaviors, but it doesn’t describe those behaviors.

Once stakeholder needs and features have been prioritized, Critical to Quality measures (CTQs) will be defined by putting measurements against the most critical of those. Needs and features that have a measurable CTQ associated with them must be written so that the measurable characteristics are part of the narrative for the Need or Feature. Stakeholders must be involved to define the need/feature to include the CTQ measures.

Features must trace to specific needs and each need must trace to the Business Opportunity/Problem Statement (see section 1.0 Project Summary).]

The Needs and Features of the project should be recorded in the traceability matrix (and attribute matrix if needed).

INSERT TRACEABILITY MATRIX HERE

INSERT ATTRIBUTE MATRIX HERE

Project Boundaries

Scope

In-Scope

[Provide a brief description of the scope of the project.]

Project Scope Diagram

[At this point in the project, a high-level future state view of the project scope puts context around the business problem. Use a high-level SIPOC or context diagram to depict this information. A SIPOC provides Suppliers, Inputs, Process, Outputs, and Customers.

If there is an existing documented SIPOC or context diagram that depicts the current state, validate and leverage this information to build the project context or scope.]

Out-of-Scope

[Provide a brief description of items that are outside of the scope of the project.]

Assumptions

[Note any initial assumptions used when developing the project Vision document. All assumptions must be validated as the project progresses. Assumptions usually become requirements (functional and non-functional) or in/out of scope items as the project progresses. Also include any high-level time-frames communicated by the line of business. (Note – this is the business’ expectation, not the estimated project timeframes.)]

Dependencies

[Note any major dependencies the project must rely upon for success, such as specific technologies, third-party vendors, development partners, other development efforts or other business relationships. For each dependency, provide a detailed description of how this effort is dependent.]

Constraints

[A constraint is defined as anything that restricts, limits, or regulates; any physical or systemic limitations.

Note any business, external (e.g. vendor, regulatory), or internal constraints (e.g. technical, legal, audit, operations) for the project.]

Product Positioning

Vision Statement

[A vision statement communicates the intent of the product and the importance of the project to all concerned personnel. The Vision statement should set the stage and establish a shared understanding of the products and stakeholders.

Provide an overall statement summarizing at the highest level, the unique position the product intends to fill in the marketplace. This statement may be easier to develop once stakeholder needs and features have been defined. The following format is recommended: (Note: either complete the table with project-specific information or delete the table from the Vision document and construct the statement as needed.)]

For	(target customer)
Who	(statement of the need or opportunity)
The (product name)	Is a (product category)
That	(statement of key benefit – that is – compelling reason to buy)
Unlike	(primary competitive alternative)
Our product	(statement of primary differentiation)

Table 2 – Vision Statement

Business Landscape

[Provide a summary of what the business competition, (e.g. other financial institutions), are doing in this space.]

Vendor Landscape

[Provide a summary of what vendor offerings are in the market place.]

Stakeholder Summary

Market Demographics

[Summarize the key market demographics that motivate the business product decisions. This information should come from the line of business. Include the following types of information: target market segments and estimate of market size and growth. Review major industry trends and technologies. The following questions will help the line of business formulate this information: What is FNFG’s reputation in these markets? What would executive management like it to be? How does this product or service support those goals?]

Business Organization Charts

[Include any business organization charts that may provide context around the structure of the organizations impacted by the project.]

Stakeholders and Key Persons

[The purpose of this section is to outline all stakeholders involved with the project. This ensures that all parties that have an investment in the project (financial or non-financial) have been identified.

Types of stakeholders can include customers, users and others who have an interest in the project. The following diagram provides types of stakeholders to consider including.

Figure 1- Stakeholder Types

A customer is defined as someone who derives business benefit from the project and provides project funding. A further breakdown of customers can include executive and working sponsors. Sponsors have the most at stake in the project and are the escalation point for the project. Sponsor influence is sometimes needed to obtain appropriate stakeholder involvement.

A user is defined as someone who comes in contact with the product, is affected by the product or has a stake or interest in the product. A further breakdown of users can include direct users and indirect users. Direct users are in direct contact with the system. Indirect users come in contact with products or by-products of the system, including operational and help desk support staff, marketing managers, legal staff, trainers, human resources staff, performance improvement staff, or report receivers.

Other stakeholders can be identified that have a stake or interest in the product or have specific knowledge about it. A further breakdown of other stakeholders can include advisors and providers. Advisors are people who never see or use the system, but have relevant information about it (e.g. audit, compliance, Information Protection, attorneys, etc.). Providers design and create the software solution by transforming requirements into the final product (e.g. vendors, architects, engineers, developers, testers, trainers, support staff, etc.).

Use the table below to capture stakeholder information including name, role, type, success criteria and issues/constraints.]

Stakeholder Table
Name/Contact	Role	Stakeholder Type	ID Wins (Success Criteria)	Issues / Constraints
[Name of the stakeholder]	[Briefly describe the role the stakeholder is assuming on the project. Describe their key responsibilities]	[Type (see Figure 1]	[Define the high-level goals and/or results desired from this stakeholder. What capabilities must be included for them to view the project as a success]	[Document any concerns, obstacles, constraints, or special work environment characteristics for this stakeholder]

Table 3 - Stakeholder Table

Common Terminology

[The purpose of this section is to ensure business and technical terms, acronyms, and abbreviations are documented and available to the project team. It is particularly important early in the project to use consistent terminology and language as it promotes effective communication and can help avoid miscommunication.

This is an ongoing activity that will continue throughout the requirements management activities. For this reason, it is recommended that new projects create a Project Glossary. Once created, the Business Analyst can provide a link in this section of the Vision document to the Project Glossary.]

Documentation References

[This subsection should provide a complete list of all documents referenced elsewhere for the project. Each document should be identified by full file name, including the path.]

Revision History

Date	Version	Description	Author
<mm/dd/yy>	<x.x>	<details>	<name>

Project Vision Document Signoff

"I agree this document represents the Vision of the project as we understand them today. I agree that changes may be made with the availability of new project information or based on project necessity. However, I realize that project commitments may have to be renegotiated based on the specific impacts of the changes."

<< Executive Sponsor Name>>	Date

Executive Sponsor

<<Working Sponsor Name>>	Date

Working Sponsor

<<Project Lead Name>>	Date

Project Lead

<<Other >>	Date

TBD